Size Change: +241 B (+0.01%)

Total Size: 1.75 MB

_{compressed-size-action}

I gave it some thought, and I don't have any definite answers but rather just some loose thoughts. I'm still getting re-acquainted with the internals of the Interactivity API after a long time away from it, so there's a chance I got sth wrong :)

attributes naming is currently confusing.

We are not currently returning actual attributes from getElement() but instead the props of the vDOM. So, we have a few options:

• Add a new property like props and "deprecate" the attributes (but we cannot remove them anymore).
• Update the interface of attributes to return element attributes. This brings me to the next point:

Returning actual attributes ?

If we wanted to return the attributes of the HTML , we'd have to figure out a way for the runtime to wait until the DOM node is mounted. It's the same reason why ref initially returns null - it's because it has not been attached to the actual DOM element yet.

So, to access the actual HTML attributes, folks can already use ref.attributes (subject to the following limitation):

ref

ref is the reference to the DOM element as an HTMLElement. It is equivalent to useRef in Preact or React, so it can be null when ref has not been attached to the actual DOM element yet, i.e., when it is being hydrated or mounted.

Therefore, changing the someValue getter to something like the following should pass the tests in this PR:

get someValue() {
	const { ref } = getElement();
	return ref.dataset.someValue;
}

However, it hits the same problem of the ref not being attached to the DOM yet.

I have been reviewing this with @DAreRodz carefully and we think the current logic is fine since it only contains the attributes of the original element. In that case, it seems correct to keep calling it attributes and not props.

Now then, since these properties are present in the Virtual DOM, they are actually the attributes that the Interactivity API is aware of. Initially, this might seem incorrect because if someone modifies the DOM imperatively, they could become unsynchronized. But after careful consideration, we believe it's safer this way because it will force people not to make imperative modifications to the DOM but to use the Interactivity API (data-wp-bind) to modify the DOM and have that reflected in the attributes that getElement returns.

Similarly, we believe that making the attributes reactive is not a good idea since it's a client-side feature and could cause problems with server-side rendering. Thus, we think the best approach is to keep them read-only and to ensure that the modification of the DOM is done with a part of the state linked to the data-wp-bind directives to ensure that server-side rendering is always correct and to avoid exposing many ways to do the same thing, which would be confusing.

In summary, there isn't much more to do in this pull request except to add some tests to confirm the current behavior.